Distributed software system visualization

ABSTRACT

A data management system stores and visualizes data generated during process management. The data management system provides different data management services and definitions of these are stored in a database. Management of data in this database is carried out by a collection of software agents, one of which, the management information agent, can access, update and download data in or from the database. Stored separately are graphical user interfaces which are downloaded to a user in accordance with the relevant service definition stored in the database when the user requests a particular data access service.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates to distributed software systemvisualisation and analysis and finds particular application inperformance visualisation and analysis.

2. Related Art

Performance visualisation and analysis is used for instance in processmanagement in order to improve management systems.

Software agents are known for use in process management and embodimentsof the present invention are particularly suited to the use of softwareagents.

A software agent can be considered as software, supported in use byhardware, which is capable of performing tasks on behalf of an entity.An agent therefore usually includes data specific to the entityconcerned, for instance data representing requirements or capabilities,and means for applying the data in decision-making processes usuallyinvolving another entity or system. Such means might for instancetherefore include a negotiation process and communication means such asa message handler.

Software agents at least theoretically can be used in the creation of aflexible and responsive virtual enterprise for process management.Agents in a virtual enterprise may be autonomous, collaborative andadaptive. That is, these enterprise agents are able to take actionswithout explicit instructions from their users (autonomous), are able toco-operate with other agents when problems are too large and complex forone to solve alone (collaborative), and are able to adapt theirbehaviours to their users and/or environments (adaptive or learning).

Each agent in an enterprise requires resources to carry out tasks and itmanages its own resources. Each agent is adapted to carry out particulartasks and it can act on its own according to its current resources andobjectives. When an agent requires a service which it cannot provide onits own, for instance running a process, it communicates with agentswhich can provide such a service, and negotiates terms and conditionsfor providing such a service. This involves contracts often known asService Level Agreements (SLAs) between agents. These effectively setout rules of behaviour for agents in collaboration. Overall tasks arethen realised by a plurality of participating agents operating inaccordance with their SLAs.

Relevant systems of this type are described in “Agents of Change inBusiness Process Management”, by O'Brien P D and Wiegand M E, publishedin BT Technical Journal, Intelligent Systems Special Issue, Vol. 14, No.4, October 1996; and in “Using Software Agents for Business ProcessManagement”, by O'Brien P D, Wiegand M E, Odgers B, Voudouris C andJudge D, published in British Telecommunications Engineering, January1997.

There are many advantages of using collaborative agents. Distributedautonomous agents are used in process management, includingdecentralised business management. Processes modelled by agents can bedynamically defined by the interaction of agents and their contractpatterns. Thus, new services can be constructed quickly in responding tomarket demands. Exceptions can be dealt with locally by agents so thattheir impact can potentially be minimised. For example, an agent canchoose another service provider (i.e. agent) if a previously selectedservice provider fails to deliver a service. Moreover, service providersfrom outside the immediate system may be used. Because agents can beprogrammed to have learning capabilities, potential problems can beengineered out and/or contingency actions can be planned beforehand.

Agents can negotiate contracts for services based on local assessment ofcost vs. benefit. Agents in a virtual enterprise work together toperform mutually-beneficial but complex tasks. In negotiating contracts,an agent performs reasoning over its resources, objectives and itsenvironment. Agents can adapt according to their environment. Theperformance or behaviour of the system as a whole results from thebehaviours of the individual agents and the pattern of contracts inplace at a current time. A change in conditions, such as theintroduction of new agents and/or services, will result in changes incosts and benefits as perceived by the agents, which will in turn resultin changes in the network of contracts and how the whole system behaves.

Collaborative software agents have been used to develop a range ofapplications. Although tools are available to assist in buildingagent-based systems, not a great deal of work has been done on how tovisualise and/or tune agents in an independent or pre-existing system tooptimise performance.

BRIEF SUMMARY OF EXEMPLARY EMBODIMENTS

According to a first aspect of the present invention, there is provideda data management system for use in storing and visualising datagenerated during use of a process management system in managingprocesses, said data management system having:

-   -   i) a request input for receiving a data management service        request from the process management system;    -   ii) a data input for receiving data inputs from the process        management system;    -   iii) a service definitions store for storing a set of service        definitions each comprising one or more service requirements in        relation to respective ones of a set of service identifiers,        including identification of data inputs required for provision        of data management services in respect of each service        identifier;    -   iv) request processing means for accessing a service identifier        in a received service request;    -   v) service identifier processing means for selecting a service        definition from the service definition store in accordance with        an accessed service identifier; and    -   vi) a data input store for storing data inputs from the process        management system required for provision of a data management        service associated with an accessed service identifier.

Generally, each data management service associated with a servicedefinition will also provide visualisation of at least one aspect of theprocess management system. The data management system will thereforeusually further comprise a library for visualisation tools such asgraphical user interface tools. In a preferred embodiment, the datamanagement system further comprises an input for loading visualisationtools to the library. This allows data management services to be addedto the capabilities of the data management system through its lifetime.

Particularly advantageously, the data management system associates datainputs with the process management system which has generated the dataand comprises means to review the contents of the data input store forentries in respect of that process management system, on receipt of aservice request from that process management system. This enables aprocess management system to make a retrospective service request, forinstance for a visualisation service, in respect of a process alreadycarried out.

Further, if the data management system also has a visualisation toollibrary, it becomes possible for the process management system to storedata inputs by means of a first service request, for a user to load avisualisation tool such as a graphical user interface to the library,and for the process management system then to use the stored data inputsto support the new visualisation tool.

As an alternative to visualisation, the data management system mayprovide data analysis. Preferably therefore, the data management systemcomprises data analysis means in place of or as well as the library forvisualisation tools.

Importantly, data analysis in embodiments of the present invention canprovide analysis at the level of inter-agent agreements as well as or inplace of analysis at the resource level.

Embodiments of the present invention can thus provide the user withpowerful tools for use in both visualisation and analysis, leadingpotentially to establishing new practices and processes, across amulti-platform, multi-functional environment, and this can be done wherethe environment has been developed independently of the invention,either before or after an embodiment of the invention itself isavailable. For instance, embodiments of the present invention canprovide information on the execution of processes, emergent behavioursof adaptive agents, and resource usage across a company's systems. Asmentioned above, embodiments of the present invention can be broughtinto use with a system to provide visualisation and analysis servicesretrospectively in respect of use of the system, and can be adapted veryeasily to meet new visualisation and analysis requirements. This is veryadvantageous for agent-based systems because these systems are dynamicand their visualisation and analysis requirements are difficult topre-specify.

In embodiments of the present invention, an agent management system(“AMS”) has been developed to provide services to management systems. Inparticular, the AMS is well-adapted to provide services to agent-basedprocess management systems (“APMSs”) and the following description isprimarily directed to use of an AMS with one or more APMSs.

The AMS uses an agent-based infrastructure which includes three mainservice agents:

1) a Management Information Agent (MIA) that provides informationservices to both agents managed by the AMS (APMS agents) and employed bythe AMS (AMS agents). The MIA uses databases to record information fromAPMS agents. Information retrieval is through an Event Query Language(EQL) which is based on the standard database query language SQL. Allrequests to an MIA from APMS agents have to be through FIPA ACL (seebelow) messages;

2) a Visualisation Agent (VA) that provides information visualisationservices to APMS agent systems. It has a library of graphical userinterfaces (GUIs) which includes a collection of visualisation softwarepackages. GUI presentation screens are constructed dynamically accordingto service requests and tools currently available in its GUI library.Information visualisation can be done on-line (real time monitoring ofin-service agents) as well as off-line (playback). In case of playback,relevant data is retrieved from an MIA database; and

3) an Engineering Agent (EA) that provides tools to re-engineer, toimprove (or fine-tune) and/or to debug in-service agents. This includesdecision support tools to analyse agent performance; tools to checkcontract compliance; tools to detect potential ‘circularities’ inrecursively defined services; and tools to assist in realisingmanagement policies to be enacted by agents. The management policiesinclude negotiation strategies, exception handling policies, resourcemanagement techniques and security policies.

FIPA ACL messages are mentioned above. FIPA is the Foundation forIntelligent Physical Agents, a non-profit organisation for promotingdevelopment of specifications of generic agent technologies thatmaximise interoperability within and across agent-based systems. It hasa home page at http://drogo.cselt.stet.it/fipa/. ACL stands for “AgentCommunication Language”, a FIPA standard.

The visualisation system for the AMS is built to be as generic aspossible. It interacts with APMS agents by exchanging standard FIPA ACLmessages. With appropriate wrappers, the AMS can be used to providevisualisation and monitoring services to other distributed systems aswell. (A wrapper in this context is a Java program for transforming datato a format for use by a particular tool. It will comprise the name ofthe tool and a list of the parameters for that tool, usually the datarequired.)

An important aspect of the visualisation system is that APMS agents canload data to an MIA database and, subsequently, can load and run a GUIat the AMS for visualising that data, for instance within the APMS, orcan load and run a data analyser.

An important aspect of the engineering agent is its ability to analysetask breakdown offline. That is, it doesn't only monitor taskperformance at runtime, which is effectively a test at the resourcelevel, but analyses task allocation in the context of the contract. Thisprovides analysis of the business process as well as monitoring at theresource level.

BRIEF DESCRIPTION OF THE DRAWINGS

An agent management system, the AMS, will now be described, by way ofexample only, as an embodiment of the present invention, with referenceto the accompanying drawings in which:

FIG. 1 shows an AMS in the context of APMSs and processes it supportsand the communications and processing infrastructure;

FIG. 2 shows the AMS of FIG. 1 in more detail;

FIG. 3 shows a block diagram of a management information agent (MIA) foruse in the AMS of FIG. 1;

FIG. 4 shows a block diagram of a request processing module for use inthe MIA of FIG. 3;

FIG. 5 shows communications paths for delivery of event information fromand between agents of an APMS and a visualisation data repository (VDR)of the MIA of FIG. 3;

FIG. 6 shows a functional block diagram of the VDR of the MIA of FIG. 3;

FIG. 7 shows the relationship between a visualisation agent (VA) of theAMS and the MIA of FIG. 3;

FIG. 8 shows a functional block diagram of the VA of FIG. 7;

FIG. 9 shows a screen presentation of an agency view of an APMS,generated by the VA of FIG. 7;

FIG. 10 shows a flow chart of steps in constructing a domain processview of an APMS, generated by the VA of FIG. 7;

FIGS. 11 a, b and c show three services provided by agents of the APMS,broken down into business processes;

FIG. 12 shows as overall service provided by the agents of the APMS as aresult of the three services of FIGS. 11 a, b and c;

FIG. 13 shows an engineering agent (EA) of the AMS and its interactionswith other components of the AMS in providing data analysis and screenpresentation of the results;

FIG. 14 shows a flow diagram of filtering and translating proceses foruse in the VDR of FIG. 6;

FIG. 15 shows a schematic diagram of a user interface response to avisualisation request;

FIG. 16 shows a protocol for handling messages in the MIA of FIG. 3;

FIG. 17 shows a relationship between agent messages and events; and

FIGS. 18 to 24 show various process views generated by the engineeringagent of FIG. 13.

DETAILED DESCRIPTION OF EXEMPLARY EMBODIMENTS

Overview of the System

Referring to FIG. 1, the AMS 100 comprises software processes or agents150 and one or more databases 155 installed on a server 105. The server105 is connected to a network 110 which can carry TCP/IP messages. Alsoconnected to the network 110 are:

-   -   one or more APMSs 115, 120 (two shown)    -   one or more sets of processes 140, 145 (two shown) which are        managed by respective APMSs    -   a distributed system 125    -   a database 130    -   a plurality of user interfaces 135 each with a display screen    -   Only one user interface 135 is shown connected directly to the        network 110 but additional user interfaces 135 may be connected        indirectly and such user interfaces are shown for example        connected via the APMSs 115, 120, the AMS 100 and the        distributed system 125.

The AMS 100 uses agents as its basic building blocks. It interacts withother systems by exchanging messages. It provides to the APMSs 115, 120and to the distributed system 125 the following main functions:

-   -   Receiving requests and making visualisation or engineering        service level agreements, particularly with APMS agents, through        negotiation.    -   Requesting data from APMS agents or the distributed system.    -   Providing permanent storage for APMS agents or the distributed        system to load data to.    -   Storing historical data.    -   Visualising data either on-line or off-line (playback mode).    -   Performing data analysis.    -   Verifying SLAs.    -   Generating solutions to improve agent performance.

The basis for interaction between the APMSs 115, 120 and the AMS 100,and the process for initiation, is as follows.

An important aspect of the APMSs 115, 120 and use of the AMS 100 is theservice level agreement (SLA) between agents. A process managed by anAPMS 115, 120 is usually too great or complex to be carried out by theresources one agent has available. The agents 172, 175 of the APMSstherefore manage processes amongst themselves (or at least can berepresented as doing so) by breaking the processes down intosub-processes and tasks and negotiating SLAs between themselves for useof the resources of multiple agents in support of the overall process.When the APMS 115, 120 requires the AMS 100 to supply a service to it,for instance visualisation or data analysis, the APMS as a whole willagain do so by negotiating an SLA, this time with the AMS 100.

An agreed interagent SLA in this environment usually identifies theagents, gives the SLA an identifier, identifies the service to beprovided by name, and records the time of start of provision of theservice. If there are multiple services and agents involved, this canconveniently be stored as an “Agent-SLA” table. The components of theservice itself, for instance in terms of tasks to be carried out andconditions to be met such as supply of supporting data, can be storedelsewhere against the service name. For instance service definitions canbe stored in an ontology accessible to the agents which require thedefinition.

If an APMS 115, 120 requires an AMS 100 to provide a service, it sends aservice request message to the AMS 100. In order to support theestablishment of the service, the message gives the AMS 100 informationabout the APMS and the resources and services it manages. The messagelists the agents of the APMS 115, 120 and the services that it managesin terms of identity and description. The description goes down to thetask level and includes setting out the order in which the tasks musthappen. The AMS 100 will store this information, for instance against anentry in an “Agent-SLA” table of its own. Once the AMS 100 and APMS 115,120 have an SLA in place, it is still necessary for the APMS to supplyits own interagent SLA details to the AMS. This occurs on start up ofthe APMS in managing the overall process it is installed to manage. Itis only at that point that the agents of the APMS negotiate and agreetheir own SLAs. The APMS will then supply an “Agent-SLA” table for itsown agents to the AMS 100 which is updated as the overall process runs.

Once the process managed by the APMS is running, the AMS 100 requestsdata from the APMS in accordance with the definition of the serviceagreed and stores it in its database 155. As long as the data wassupplied and was not corrupted or refused for security reasons forinstance, the AMS 100 can then use the data in visualisation andanalysis at any time on request of the APMS 115, 120.

To visualise the data, the AMS 100 selects a GUI from its GUI library156. Importantly, if a suitable or requested GUI is not in the library156 when a visualisation service is requested, it is possible to load asuitable GUI at a later time and use the new GUI to analyse or visualisedata previously loaded to the database 155.

A service as described above can also be provided by the AMS 100 inresponse to a user request. There does not have to be an existing SLAbetween the AMS 100 and the APMS 115, 120.

All agents in the AMS 100 are FIPA compliant. They interact with eachother by exchanging FIPA ACL messages. The contents of the messages ofthe AMS agents 150 are represented by an Event Query Language (EQL). EQLis based on SQL. Details of EQL are described further below. Theinteractions between AMS agents and APMS agents are also done byexchanging FIPA messages. The contents of those messages are representedby using the Process Interchange Format (PIF) language (a known languagewhich is published on the Internet for example athttp://ccs.mit.edu/pif/) and a common shared ontology (shared vocabularyand their semantics) which is also described in later sections.

The AMS 100 offers services to agents of other systems, as long as thoseagents are configured to communicate correctly, for instance viainterface agents 165, 170. When an agent requests a service from the AMSsystem, it sends FIPA ACL request messages to the AMS system. Uponreceiving a request, for instance from APMS agents, the AMS 100 willdecide whether it can provide the requested service. This will bedecided on its current resources. If a service can be provided, the AMSwill send a positive response with any preconditions. If this isaccepted by the requesting agent, an SLA is made. The preconditionsspecify what the requesting agent has to provide to the AMS 100. Forexample, if an agent would like the AMS 100 to display the states of anactivity over a period of time, it has to give the activity states tothe AMS 100.

Each APMS 115, 120 provides a management system for a set of processes.For instance, a first APMS 115 together with its processes 145 mightprovide a workflow-based work distribution system as described in“Agents of Change in Business Process Management” (referenced above). Asecond APMS 120 together with its processes 140, which may be installedon two or more separate platforms, might provide a business processmanagement system as described in “Using Software Agents for BusinessProcess Management” (referenced above). Importantly, each APMS 115, 120and the AMS 100 is provided with means to communicate using FIPA ACLmessages via an interface agent 165, 170.

The distributed system 125 is similar to an APMS 115, 120 but is notnecessarily agent-based. It also runs and manages processes and isequipped to communicate using FIPA ACL messages.

The database 130 represents data accessible via the network 110 and mayin practice comprise a plurality of separate databases, accessible bymeans of one or several database query languages. It carries data tosupport the processes managed by the APMSs 115, 140.

User interfaces 135 are provided. These may be to the AMS, either orboth of the APMSs, and via the network 110 to any of these or to thedistributed system 125. Importantly, visualisation and engineeringservices provided by the AMS 100 can be run from any one of these userinterfaces 135. Alternatively, other agents or processes, for instancewithin an APMS, might request a service from the AMS 100.

2. The AMS 100

Referring to FIG. 2, as mentioned above the AMS 100 comprises three mainservice agents 150, the visualisation agent (VA) 151, the managementinformation agent (MIA) 153 and the engineering agent (EA) 152. The AMS100 uses the VA 151 to provide visualisation services to an agent-basedsystem by offering a selection of views of that system to the user. Ituses the MIA 153 to provide information services such as long term datastorage and access. It uses the EA 152 to provide performance-relatedservices such as analysis and diagnosis of agent performance.

The AMS 100 communicates via the network 110 through an interface 170and data incoming from APMS agents 172, 175 is stored in the database155 by the MIA 153. This stored data can only be accessed via the MIA153. The VA 151 has a GUI library 156 available to it.

In addition, the AMS 100 comprises an EXE 200 and a data analyser 205.The EXE 200 comprises known functionality, used by the VA 151, tocontrol run-time environments such as maintaining currently activepresentation screens and which data is related to which presentationscreens. The data analyser 205 may be any suitable data analysis tool tosupport the engineering agent 152.

2.1 VA Functions

The VA (Visualisation agent) 151 is responsible for providingvisualisation services. For instance, it can generate a set ofpresentation screens such as bar charts, pie charts and linked graphs.The VA 151 manages the GUI library 156 which holds a collection of datavisualisation packages. Any visualisation request, by a user or by anAPMS 115, 120 for instance, will trigger the VA 151 to constructpresentation screens by using tools in its GUI library 156. Thevisualisation services provided by the VA 151 can be on-line (real time)as well as off-line (playback). Data required for visualisation servicesare pushed by the MIA 153, i.e., the MIA 153 sends data to the VA 151.In case of playback, the MIA retrieves the data from its database andsends it to the VA 151 according to an agreed rate. In case of real timevisualisation, the MIA 153 first transforms the raw data from the APMSagents 172, 175 into a required form, sends it to the VA 151, and onlythen stores the data in its database 155.

Key to the visualisation aspects of the AMS 100 is the use of the GUIlibrary 156 to hold a collection of presentation tools and/or softwarepackages. The GUI library is managed by the visualisation agent 151 ofthe AMS. Upon receiving a new visualisation request, the visualisationagent 151 will decide whether the service can be provided by reviewingits current commitments and what presentation screens can be constructedfrom its GUI library. In addition, the MIA 153 is consulted as towhether the information can be transformed to a particularrepresentation which a tool requires. If a service can be provided, thevisualisation agent will compose the requested visualisation screens.

The composition of visualisation screens available in response toservice requests offers an unlimited number of information views. Usersare no longer limited to choose among a fixed number of presentationscreens because it is a relatively simple matter to add tools to the GUIlibrary 156. Indeed, the construction of presentation screens from theGUI library according to service requests gives the AMS 100 thecapability to offer services which may not have been even envisaged bythe system designers. Data from an APMS 115, 120 can be stored atruntime and then potentially visualised at some later date, using alater-developed GUI. It is relatively easy to incorporate newpresentation tools into the AMS 100. All that is required is to wrap thetools appropriately (“wrapping” is a known software engineeringtechnique for creating compatible interfaces between a piece of softwareand an environment for which it was not necessarily built) and load themto the GUI library 156.

2.2 EA Functions

The engineering agent 152 of AMS provides data analysis and verificationservices to APMS agent systems. The EA (Engineering agent) 152 isresponsible for fine-tuning APMS agents 172, 175 by diagnosing problemcauses, checking contract compliance and making recommendationsaccording to its observation of their performance. It interacts with theMIA 153 to obtain historical data from the database 155, with a dataanalyser 205 to analyse the data and with the VA 151 to display results.Whenever appropriate, the engineering agent 152 also makesrecommendations to APMS agent systems 115, 120 on how to tune itsagents. It can be used to track down causes for a problem and comparethe agreed SLAs with the actual services carried out.

Again, known diagnostic systems build these functions into actualapplication systems. AMS diagnostic functions are offered as serviceswhich can be requested by other agent systems.

2.3 MIA Functions

The MIA 153 has two aspects. It provides information services to APMSs115, 120 and it provides data services for the VA 151 and the EA 152. Tosupport the data services to the VA 151 and the EA 152, it uses at leastone database 155 (an Oracle™ database) to store agent activities andtheir states. This provides data for the visualisation agent 151 to playback any episode of APMS agent activities and for the engineering agent152 to carry out data analysis. To support the information services toagents or users outside the AMS 100, the MIA 153 can store datapermanently on request. Thus, APMS agents can request the AMS 100 toprovide permanent data storage, and information about other APMS agentsand/or system wide information if security requirements are satisfied.

The MIA 153 operates to the pre-defined common shared ontology and EQLqueries. Any agent can request MIA services which are defined in thepre-defined common shared ontology. Some services to VA and EA arepre-defined so that no negotiation is required for VA and EA to usethese services.

The question of shared ontologies is a known one and relevantpublications are “A Translation Approach to Portable OntologySpecifications” by Gruber TR, published in Knowledge Acquisition, 5(2),1993, and “Collaborative Engineering based on Knowledge SharingAgreements” by Olsen G R, Cutkosky M, Tenenbaum J M and Gruber T R,published in the Proceedings of the 1994 ASME Database Symposium, 1994.

The MIA 153 can be viewed as providing two aspects of functionality andis in fact shown in that manner in FIG. 2. It provides a negotiationinterface function 170 to the AMS 100 as a whole. It also manages allaccess to the database 155. If a request is received from an APMS 115,120 to store data, it is the MIA 153 which will receive the request andnegotiate an SLA between the AMS 100 and the requesting agent.Subsequently all data under this agreement will be loaded to thedatabase 155 via the MIA 153. If a request is later received to retrievepreviously stored data, it is the MIA 153 which will review the requestand, if the request is legitimate, retrieve the data from the database155 and send it to the requesting agent. If an agent requests data towhich it is not entitled to have access, the MIA 153 will detect thatand respond accordingly.

The MIA 153 stores data from APMS agents either in its original form orin a changed form. If a data storage service is requested which is notrelated to the VA and/or the EA, data is stored in its original form.Otherwise, data is changed into a predefined format before being storedin the database. This includes data for visualisation and/or engineeringservices. Data for run-time visualisation services is also stored in thedatabase in a changed format unless the requesting agent instructsotherwise.

If a request is to analyse and to diagnose agent performance, the MIA153 of the AMS 100 will similarly make an SLA with the requesting agentaccording to the capability of the EA. The MIA 153 will load all data tobe stored under this agreement in its database 155. When all therequired data has been received, the EA 152 will retrieve it from thedatabase 155 by means of the MIA 153, carry out the agreed service andthen either display the results in a GUI interface or forward them tothe requesting agent as appropriate.

In the embodiments described below, the server 105 supports a UNIXenvironment and the AMS agents 150 are implemented in JAVA (see theJavasoft home page at http://java.sun.com/), and OrbixWeb from IONA Inc(see the Orbix/OrbixWeb home page at http://www/orbix.com/). Theyexchange FIPA ACL messages with APMS agents through CORBA IDL interfaces(see the CORBA home page at http://www.omg.org/). Thus the AMS 100 canrun on many different computing platforms and can be remotely contactedby APMS agents 170, 175.

The use of agents enables the system to scale up. The system can beeasily upgraded, and new services can be easily constructed. AMS isimplemented based on the platform independent CORBA standard so that itcan be contacted by a large number of systems.

The database 155 is an Oracle database, accessible using Pro*C and C++languages.

3. Visualisation and Engineering Requirements in the AMS 100

The AMS 100 is principally designed to manage agent-based systems. Thedynamic, autonomous and adaptive nature of agent-based systems requiresa flexible agent management system. The AMS 100 can provide informationabout both what has happened and is happening within an agent system,particularly agent interactions, their resource usage and theirunderlying business processes. It can also provide decision supporttools to analyse agent performance and to re-engineer in-service agentsto optimise their performance.

3.1 Visualisation Requirements for the AMS 100

Agent system visualisation in the AMS 100 has three perspectives:

-   -   Agency view—views of agent interactions and their relationships;    -   Agent view—states of an agent. This includes tasks and resources        controlled by the agent; and    -   Domain view—views of the business processes enacted by agents.

These three views are inter-related. It should be possible to access anyview from any other views. Preferably, whenever appropriate andpossible, animation and 3D display should be employed.

Referring again to FIG. 1, where the AMS 100 is managing an APMS 115,120, the agency view is that of interactions between the agents 172, 175within a single APMS. The agent view is of a single one of the agents172, 175 in an APMS 115, 120 and the domain view is a view of theprocesses 140, 145 managed by an APMS.

3.1.1 Agency View

Agency view provides users with various views of the interactionsbetween agents. This includes how agents are interconnected, theirhierarchies, and communication patterns among them. The interactionsbetween agents should be marked by message types and appropriate links.Agents should be represented as appropriate icons to reflect their typesand their task states. It should be easy to see through its staterepresentations whether an agent is idle, active, overloaded, failed,etc.

As agent systems may employ a large number of agents, the system shouldbe able to show users only those agents they are interested in. Throughthese views, users should be able to view only those interactionsconcerning a particular type of message. Important messages should beindicated as such, and the most recently sent messages should beavailable for user inspection.

The user should have access to the contents of any message passedbetween some specified pair of agents by specifying which messages he orshe is interested in. The messages should be displayed or replayed inhuman-readable form.

Users should be able to visualise these in real-time as well as to playback any episode of activities whenever required. The playback should beable to play in slow motion and/or pause modes.

3.1.2 Agent View

Agent view is used to show states of any given agent. Agent statesshould include at least the following:

-   -   Execution states of tasks;    -   Resource usage;    -   SLA details;    -   Negotiation strategies;    -   Agents currently in contact.

This should be available at several levels of details, ranging fromwhich rule the agent is currently executing to how active the agent is.Both a list of the most recently accomplished tasks, and the tasks aboutto be attempted, should be available to the user. It should be possibleto show how states were arrived at and why decisions were made.

There should be facilities for the user to probe each message and/ordecision sent or made by an agent to several levels of detail.

3.1.3 Domain View

Domain view is used to display any information about the underlyingbusiness processes managed and enacted by agent systems. For instance,in the domain view, it is possible to display which of the tasks and/orsub-business processes which together provide a complete businessprocess or task is controlled by which agent. It is also possible in thedomain view to animate the execution of business processes, showingwhich tasks have been executed, which tasks are currently executing andwhich tasks are going to be executed. The user should be able to obtaindetails about which agents are responsible for which tasks. The domainview therefore includes:

-   -   views of each specific instance of a business process,        sub-process or task, identifying the exact status of that        particular process invocation    -   views of the percentage utilisation of a specified resource    -   views of the utilisation trend of resources for a specified        service    -   views of the overall aggregate utilisation of specified        resources    -   views of contract compliance    -   views of detailed contract compliance

For instance, a Contract Compliance View is used to display aninstantaneous view of a number of agent agreements. Each task type isrepresented by a set of bar charts which present different aspects ofthe business processes with respect to the agents' contracts. A DetailedContract Compliance View is used to visualise agent agreements and anactual flow of data over a period of time.

Referring to FIGS. 1 and 3, an example of the AMS 100 used invisualisation might be as follows. (Although the following refers to aselected APMS 120, it could equally refer to another APMS 115 or to adifferent distributed system 125.) An APMS 120 is running, managingtasks and resources such as processes 140. In managing the tasks andresources, messages pass between the APMS 120 and the tasks andprocesses 140, and between agents 175 of the APMS 120. The agents 175will also change state. Depending on the visualisation or engineeringservices selected in respect of the APMS 120, the APMS 120 will haveregistered those services with the AMS 100. For instance, the APMS 120will have requested the AMS 100 to store data, including messages and/orstates, in the Oracle database 155. The APMS 120 will transmit this datato the AMS 100 in accordance with the current definition of the servicerequested.

At the AMS 100, the MIA 153 will load this incoming data to the Oracledatabase 155 in a form relevant to the service, again as currentlydefined for that service.

A user, who may be at a personal computer as user interface 135 attachedto the AMS 100 or attached to the TCP/IP network 110, or indeed attachedto the APMS 120, desires to use the AMS 100 for a service in respect ofthe APMS 120. The user therefore accesses the service front end andselects, as an example, a visualisation request. The user is now offereda menu of different visualisation services, such as:

-   -   2D agency view    -   3D agency view    -   agent view    -   business process (domain) view

The user selects, for instance, the agent view by clicking on that itemin the menu. This allows the AMS 100 to access a definition of the agentview visualisation service. The definition will require a particular GUIto be loaded from the GUI library 156 in order to present data from theOracle database 155 to the user in a pre-determined manner. The AMS 100will therefore search the GUI library 156 for the specified GUI. If theGUI tool is present in the library 156, the AMS 100 will start up thetool and use the MIA 153 to access the Oracle database 155 for the datarelevant to that visualisation service, again as defined by the ontologylibrary and as specified by the GUI tool.

If the GUI tool is not present in the library 156, the AMS 100 front endwill notify the user that their service request cannot be satisfied.

3.2 Engineering Requirements for the AMS 100

The engineering agent (EA) 152 provides tools for timely analysis ofagent performance based on key performance indicators, diagnosis of thecauses of problems and the provision of statistics based on past agentperformance.

In particular tools are provided to:

-   -   classify agents into good and bad workers    -   determine causes of non-contract compliance    -   detect and indicate potential circularities in recursively        defined services    -   identify when new services are necessary (perhaps to overcome        problem areas), and when existing services are sufficient to        achieve an overall business objective    -   determine the placement and distribution of services    -   assist in realising management policies to be enacted by agents        e.g. negotiation strategies; exception handling policies;        resource management techniques and security policies    -   identify cases where agent communication should be optimised    -   group agents by their closeness. Closeness can be measured by        the number of messages exchanged between agents, the number of        SLAs made between agents, and so on    -   display suitable warning messages whenever problems are detected        such as that a monitored agreement has been broken

For instance, the EA 152 may classify agents as good and bad workers byapplying a threshold of 80% SLAs met for an agent to qualify as a goodworker. Failure of a service is defined by the APMS agents and the EAsimply provides measurement in that respect. The EA can though addconsiderable value by identifying agents that are often or consistentlyfailing and thus indicating a possible diagnosis of a problem that needsresolution.

The EA 152 is equipped to send messages whose content is determined bythe results of these functions and the sending of such messages, andtheir destination such as the relevant APMS, can be determined by theuser.

3.3 Information Management Requirements for the AMS 100

The AMS 100 provides information services to both AMS agents and APMSagents. There are two main requirements:

1. to store information permanently and to provide this informationstorage service to other agents or systems; and

2. to allow information retrieval using high-level query languages.

The AMS 100 provides information to any agent if the request isreasonable. However, information security is also provided for instancesuch that confidential information cannot be accessed by any agent otherthan the owner. Techniques for this are known and further description isnot given here. If an agent stores information, that agent can retrieveit whenever it requests.

In order to fulfil the requirements of the VA 151 and the EA 152, theinformation stored in the database 155 is as generic as possible. Someinformation translation will be provided by the AMS 100. The VA 151 andthe EA 152 retrieve information from the MIA 153 by issuing high-levelqueries and/or Java Database Connectivity (JDBC) queries. However,information security should not be compromised.

3.4 Non-Functional Requirements for the AMS 100

From a non-functional perspective it is advantageous that the AMS 100is:

-   -   scaleable so it can handle varying numbers of        agents/services/tasks    -   robust so that despite all the potential crashes that might go        on in an agent system, the AMS 100 does not hang    -   able to display multiple independent windows in an open graphics        environment, i.e. it provides respective windows for each        service and/or for each agent    -   able to run on many platforms    -   able to deal with many agent systems connected at the same time    -   able to take account of the various technologies that may be        employed (now and in the future)

Preferably, it can filter out irrelevant information and limit thequantity of information displayed. The rate of information output canpreferably be controlled by the user.

The visualisation and engineering system is preferably flexible and ableto be used in conjunction with a large number of agent systems ordistributed systems.

4. System Components and their Design Details

4.1 Management Information Agent 153

Referring to FIG. 3, at the highest level, the MIA 153 consists of threemodules: a request processing module 300, a visualisation datarepository (VDR) 305, and a service management module 310. The requestprocessing module 300 communicates with APMS agents and processesmessages accordingly. The visualisation data repository 305 definesmethods for storing and retrieving information from MIA databases. Italso defines a set of APIs which allow AMS agents to access the databasevia JDBC query calls and PL/SQL queries. The service management module310 maintains a record of all VA and EA requests. It is also responsiblefor sending (or pushing) data to the VA 151 and/or the EA 152.

(Information on JDBC can be viewed athttp://java.sun.com/products/jdbc/index. html. Information on PL/SQL canbe viewed at http://www.oracle.com/)

Referring to FIG. 4, the functional components of the request processingmodule 300 are as follows:

Communication Defines methods for sending and receiving module 400messages from and to the APMS agents. IDL-ACL message Messages from AMPSagents are IDL method calls. handler 405 FIPA ACL messages are extractedfrom these IDL messages. ACL message Processes FIPA ACL messagesaccording to handler 410 appropriate FIPA protocols and extracts messagecontents. However, contents are not processed here. Contents handlerProcesses the request according to its current 415 resources andobjectives, and responds subsequently. In case of requesting informationfrom MIA database, security check will be performed. ACL-IDL messageWraps up FIPA ACL messages as IDL method calls wrapper 420 and sendsthem to APMS agents via the send- message function defined in thecommunication module.

Within the communications module 400, a receive messages module 425defines CORBA IDL interfaces which can be called by ARMS agents. Theseinterfaces are implemented as Java methods using the skeleton producedby the OrbixWeb IDL compiler. Similarly, a send messages module 430defines CORBA IDL interfaces which can be used to send messages to theARMS agents. These interfaces are also implemented as Java methods usingthe skeleton produced by the OrbixWeb IDL compiler.

At the heart of the MIA 153 is the VDR 305 which captures and storesinformation from APMS agents. Two types of information may be madeavailable to the VDR from APMS agents:

-   -   Agent Communication—the messages that agents send and receive.        The transmitter of information to the VDR could be either the        sender or the receiver of the message, or both.    -   Agent State—the internal condition of an agent. The transmitter        of information to the VDR would (normally) be the agent        concerned, whenever its internal condition (state) changes. Note        that the concept of ‘state’ for an agent can be expected to be        specific to a particular ARMS. It will depend also upon the        business monitoring and engineering requirements, agent        co-operation policies, and effective authentication measures to        protect the privacy of information.

Referring to FIG. 5, a set of APMS agents 175 within an APMS 120communicates amongst themselves using messages 500. Each agent 175 mayundergo changes of state during use of the APMS 120. Both the messagesand the state changes are represented as ‘events’ 505 that occur in theAPMS 120 and are transmitted to the VDR 305.

Referring to FIG. 6, the main components of the VDR architecture are thefollowing:

Data collection module 600

-   -   This receives the incoming events 505 from the APMS 120,        translates them into an internal (standard) format, filters out        those that are not required, and stores the remainder into a        database 650 (see later sections for details). The APMS accesses        this module via a VDR-store interface 610.

Data retrieval module 605

-   -   This allows events to be recovered from the database by the VA        and/or EA tools. In order to provide an abstraction from the        underlying database technology, an Event Query Language is        provided within this module. It allows the VA 151 and/or the EA        152 to define quite complex requests. For example, a query may        request every negotiation message that agent A has received        since 20:45:50 hours.

The data collection module 600 provides:

Interface to VDR store Java methods which are called by Contents 610Handlers to add data to the event database 650. Event Filters 615 Pro*Cfilter programs which perform event filtering. Some irrelevant data isthrown away at this stage. Comms. Event PL/SQL programs that translateinter-agent Translators 620 messages to database syntax. State EventTranslators PL/SQL programs that translate intra-agent 625 messages todatabase syntax. Store to Database 630 SQL insert statements. The dataretrieval module 605 provides: Retrieve from Database SQL selectstatements. 635 Event Query Language EQL parsers. 640 Interface to VDRQuery APIs for VA/EA to retrieve data from the 645 database.

The filters select out data which will be redundant in the AMS 100. Forinstance, each APMS agent party to an agreed SLA will notify the AMS100. Only one event signifying agreement of the SLA is required for theAMS 100 and the filters 615 will discard subsequent events notifying thesame SLA.

The communication and state translators in the data collection module600 are configurable to a particular APMS. The syntax of thecommunication messages and agent states in the APMS are mapped/convertedinto a standard event syntax by the translators. Semantic mapping isalso required for instance to deal with naming discrepancies betweenAPMS agents and the AMS 100 for the same service or task.

Filters and translators are further discussed below under the heading“4.5 Filters and Translators” and with reference to FIG. 14.

4.2 Visualisation Agent 151

Visualisation agents are responsible for constructing presentationscreens according to requests from APMS agents. They interact with theMIA 153 through a set of AP Is. At the highest level, visualisationagents 151 can display agent information in three views: agency view,agent view and domain view.

Referring to FIGS. 2 and 8, the VA 151 interfaces to the MIA 153 byissuing a set of APIs 800 which are EQL queries. In particular, thefollowing APIs are defined:

TABLE 1 VA and MIA APIs. setup (Agent, View) set up the view View foragent Agent. get_agent_state (Agent, get the activity states foractivity Activity of Activity, States) agent Agent, and put results inStates. add_information (Agent, MIA pushes the data Data of agent AgentData) to VA

The VA 151 constructs presentation screens 820 according to requests andtools from its GUI library 156. It also keeps track of what presentationscreens 820 are currently active and how to feed data to eachpresentation screen 820. The four functional components of the VA 151and their relationships are as follows:

Communication interface 800:

-   -   defines a set of APIs for interfacing with the MIA 153, (see).

Context controller 805:

-   -   controls requests and decides whether the request can be        provided.

Presentations constructor 810:

-   -   constructs the presentation screens 820 if the Context        controller has decided that a request can be provided.

Presentation EXE 815:

-   -   enacts the presentation screens 820.

The context controller 805 keeps a record of what screens 820 arecurrently active and deletes them when they are no longer required. Bymonitoring the screen presentations already open for a user, the contextcontroller ensures that only correct data is sent for thosepresentations. On receiving a request from a user, the contextcontroller looks to see what is open. If the request requires a new GUI,the context controller provides that, or for instance provides a failmessage to the user if it cannot.

Referring to FIG. 15, the way in which the user uses the VA 151 is asfollows. The user may access the AMS 100 from any terminal 135, usuallyvia an authentication procedure. The AMS 100 provides a graphical userinterface at the terminal 135 by means of which the user can select anoperation. This operation might be administrative or for use of the AMSwith respect to a specific APMS, depending on the role and requirementsof the user. If the user requires operation of a visualisation service,the user will select a visualisation request via the front end GUI ofthe AMS 100. If the user request comes via an APMS 115, 120, the AMS 100may be equipped to identify that APMS as the subject of thevisualisation request. Otherwise, the user will be prompted to identifyan APMS 115, 120. The visualisation request will trigger the VA 151 todeliver browser capability to the terminal 135 for the user so that theuser can download selected views of the APMS 115, 120 in question.

The browser will offer a drop down menu 1500 of the selection of viewsavailable via the VA 151 irrespective of the relevant APMS 115, 120.These might comprise the 2D agency view, the 3D agency view, the agentview and the business process view. The VA 151 can build each view usinga tool from the GUI library 156 together with data extracted from theOracle database 155. Selection of a view by a user constitutes a commandwhich then runs the relevant tool. To present the view to the user, theVA creates files for downloading. The agency and agent views may becreated as HTML or VRML files appropriately, and these constructed filesare downloaded to the terminal 135 for the user. The business processview is expressed in a more relevant format, such as constructed by aDaVinci™ package. (The DaVinci package is a known graphicalvisualisation system and information is available over the Internet atURL:

http://www.informatik.uni-bremen.de/˜davinci/docs/overviewF.html.)

4.2.1 Agency View Design

Referring to FIG. 9, an agency view presents agents in an agent systemand how they are organised and their interactions. In the view shown,agents are depicted by icons 900 and agent interactions (messages andcontracts) are indicated by connecting lines 905.

There are a number of icons 900 which represent types of agents inagent-based applications. Each icon is intended to have intuitivemeaning and can be selected or reselected by the user. The arrangementof agents in the agency view can be according to the hierarchy in theirapplications as designed by their designers.

The functionality is not limited to displaying messages and contracts.It also includes the ability to select agents, messages and contractsusing a mouse pointer or other known means, to ‘pull up’ more detailedinformation. In the case of agents, for example, on selection of an icon900 a menu allows the user to launch more views to display details ofthat agent's performance, resource allocation and other internal states.It also allows a user to drill down to agent views and domain views.

To support the AMS goal of allowing the user to customise viewsin-service to meet specific interests it also allows the user toconfigure the agency view. Configuration options include adding andremoving agents from the view, positioning and repositioning the agentsto create a clear and intuitive layout and selecting the type ofmessages or agreements which should be displayed.

The functions supporting the agency view consist of four main modules:

1. a view panel onto which the agents and links connecting them can bearranged and rendered. This panel is responsible for the overall layoutof agent views and co-ordinates the drawing of links 905 between agenticons 900;

2. a node element module responsible for the icons 900 representing theagents on the view panel. In the agency view, the agents are representedat nodes of what is effectively a network. Each node is represented byan icon 900 in the agency view. These icons 900 must be able to adoptany number of appearances in order to express the type of agent beingrepresented. They are moveable, together with the node they represent,by drag and drop operations and capable of being created and destroyedand added or removed from the display by the monitoring application.They are also required to be able to produce pop-up menus should theapplication require this.

3. a connecting line module is responsible for joining the icons. Itallows them to represent any potential interaction between agents inwhatever way the application desires. The connecting lines 905 must alsobe labelled or marked in some way such that the user can identify them.As with the icons 900, the lines 905 must be capable of producing pop-upmenus to supply further information and other options to the user.

4. a menu module allows menus to be defined and attached to icons and/orlines.

4.2.2 Agent View Design

The agent view allows users to inspect information relating to anyparticular agent. This includes the resources available to the agent,their status, SLAs made and messages sent. This view is attached to anicon 900 or line 905 which represents the agent concerned. Selection ofthe icon by a user displays pull-down menus with menu items representingvarious aspects of agent details.

The VA 151 retrieves agent details from the MIA 153 and constructs themenus accordingly. When a menu item is selected, details about thatparticular aspect of the agent will be shown either as text or graphicssuch as line graphs, bar charts, etc. All agent data used by the VA 151is retrieved from the MIA 153 which obtains agent states from APMSagents through appropriate FIPA communicative acts and protocols.

The VA 151 determines how to present information according to requesttypes and what tools are available in the GUI library 156. The VA 151maintains a list of events which in turn represent requests. When anevent occurs, the VA 151 will check the event, get appropriate data andforward it to presentation screens.

The functions supporting the agent view consist of the following mainmodules:

-   -   Event module which is responsible for event handling. It keeps a        list of events and how to respond when events occur.    -   GUI library module which is responsible for maintaining the GUI        library 156. This includes a record of capabilities of        presentation tools, adding new presentation tools and deleting        existing presentation tools to and from the GUI library.    -   Data translation module which is responsible for transforming        data to appropriate forms required by presentation tools.    -   Interface module which is responsible for interacting with the        MIA 153. It defines a list of APIs between the MIA 153 and the        VA 151.        4.2.3 Domain View Design

The domain view concerns the underlying business processes enacted byAPMS agents. The domain view is responsible for constructing domainprocesses and displaying them. The domain view can construct businessprocess views from PIF descriptions. If the business process is not inPIF format, domain specific programs have to be constructed manually.The following describes how domain views are constructed from PIFdescriptions.

Agent services are defined as PIF processes. Services are definedrecursively, i.e. a service may be made up of a number of sub-services.Tasks are atomic services. Each agent holds PIF descriptions for theservices it offers and the AMS database 155 holds PIF descriptions forthe services managed by APMS agents, as loaded when the SLA between theAPMS and the AMS has first been agreed. Domain processes are constructedfrom services made up those domain processes. The construction processis shown in FIG. 10.

Given an instance “s” of an agent's service, the domain processconstruction program first gets the service description PIFs from theagent (STEP 1000), and then identifies sub services and which agentsoffer which sub services. Next, sub service PIFs are obtained fromagents in question (STEP 1005). The process diagram is constructed fromall the component PIFs by analysing the relations between them (STEP1010). Finally, the domain process is shown via the DaVinci package(STEP 1015).

For example, let us suppose that agent A1 offers Service 1 for which thePIF process is as shown in FIG. 11 a and Service 2 and Service 3 areoffered by agent A2 and agent A3 respectively and are as shown in FIGS.11 b and 11 c. The process construction program gets PIFs for Service 1from A1, PIFs for Service 2 from A2 and PIFs for Service 3 from A3. Theprocess diagram for Service 1 is constructed as shown in FIG. 12.

Domain processes are displayed by using the DaVinci package. Thefollowing steps provide the construction and displaying of processes:

Retrieval of PIF data from the AMS database 155 via the MIA 153.

PIF to DaVinci conversion which analyses PIF descriptions and constructdisplay orders for all activities in the process.

4.3 GUI Library

The GUI library 156 holds a collection of presentation tools. They canbe accessed by the Visualisation agent 151. Each tool has to be wrappedup (as mentioned above) before putting into the library.

In the VA 151, the details of presentation tools are represented by avector of objects which specify types of the tools, data formats and howto invoke them. The GUI library 156 may hold for instance the followingpresentation tools:

-   -   Dynamic menu constructions,    -   DaVinci based tools to display business process diagrams,    -   Clustering graphs,    -   Line graphs,    -   Bar charts in 2D/3D,    -   Pie charts, and    -   Percentage graphs.        4.4 Engineering Agent

Referring to FIGS. 2 and 13, the EA 152 is responsible for in-serviceagent engineering and decision support. The overall architecture of theengineering agent is as shown in FIG. 13. It has a core processingcomponent for the EA 152 and interfaces to the MIA 153, Oracle database155, data analyser 205 and the VA 151. The interface to the database 155is via a wrapping component which provides to the EA 152 a high-level,MIA-independent event query language for retrieving data.

Requests may be received by the EA 152 either from an APMS 115, 120, adistributed system 125 or a user via a terminal or personal computer135. A request identifies the service required of the EA 152 and isreceived as a message. The MIA 153 which receives and processes allincoming messages to the AMS 100 runs a check on whether data necessaryfor provision of the service is present in the database 155. If the datais missing, the MIA 153 returns the request for the missing data. If thedata is present in the database 155, the MIA 153 passes on the requestas a message to the EA 152. The EA constructs an EQL request to retrievedata from the database 155. If the incoming service request identified aservice in relation to the business processes managed by the relevantAPMS 115, 120 or distributed system 125, the data the EA 152 downloadsfrom the database 155 will include the PIF service descriptions for theservices managed by the APMS 115, 120. The EA 152 will construct abusiness process from the PIF descriptions, as described above withreference to FIGS. 11 and 12, and send the constructed process orprocesses to the data analyser 205.

The data analyser 205 may comprise any data analysis tool which cansupport services the EA 152 may have to provide. An example of such ananalysis tool is the concurrency workbench, a semantic based tool forthe verification of concurrent systems. Publications in relation to thistool include “The Concurrency Workbench: A Semantics-Based Tool For TheVerification Of Concurrent Systems” by Cleveland R, Parrow J, andSteffen, B, published in the proceedings of the Workshop On AutomatedVerification Methods For Finite-state systems, Lecture Notes On ComputerSciences 407, published by Springer-Verlag in 1989, and “The ConcurrencyWorkbench: A Semantics-Based Verification Tool For Finite-State Systems”by the same authors, published in ACM Transactions on ProgrammingLanguages and Systems, TOPLAS, 15(1): Pages 36–72, 1993. The Workbenchis also available over the Internet athttp://www.dcs.ed.ac.uk/packages/cwb/. It is however necessary totranslate business processes expressed in the Process Interchange Format(PIF) to the calculus of communicating systems (CCS) in order to use theWorkbench. However, it is then possible to verify properties such asdeadlocks, livelocks, safety and liveness. The EA 152 communicates withthe Workbench by making function calls.

The EA 152 is capable of displaying various views in relation tobusiness processes managed by agents of the APMS 115, 120. The servicerequest identifies whether for instance the EA 152 should displaybusiness processes themselves, for instance using the DaVinci package,whether to display a summary of business processes, for instance usingan HTML file or whether to only display information where a problem hasbeen identified. The EA 152 interacts with the VA 151 in order todisplay information. For instance, the EA 152 may deliver suitablebrowser functionality to the VA 151 together with content for displayvia HTML, VRML or DaVinci files.

Given data accessed from the database 155, the EA 152 can generateresults in various formats. For the agency view, it can produce a 3Dtrace of the agents' communications and it can also provide a 2Dclustering of agents to visualise their closeness, as well as a pagecontaining statistical information on the multi-agent system. Forparticular agents, the EA can provide a detailed analysis of the agent'sperformance including a recommendation concerning its workload. For thedomain view, the EA 152 provides monitoring of the SLA execution. Torealise this service the EA translates the temporal order of businessprocess SLAs into a graphical language understandable by the graphicaldrawing tool DaVinci.

The interface to the visualisation agent 151 is a thin component sincethe EA 152 provides most results as HTML, VRML, DaVinci pages or Javaapplets. (It is the applets which deliver the browser functionality tothe VA 151.)

The engineering agent (EA) accesses data which has been loaded to thedatabase 155 by the Management Information Agent (MIA) 153, processes itand makes it available for presentation to the user or information ofother agents. The data available from the MIA comprises sender ID,receiver ID, sending time-stamp, receiving time-stamp, message type,message contents, and application-dependent information on tasks,services, and service level agreements, etc. The methods to analyse thisdata can be grouped according to their complexity.

-   -   First, there are syntactical methods which comprise counting the        number of messages and amount of data sent and received by an        agent, a list of agents a particular agent is in contact with,        and a list of speech acts the agent received and sent. The        latter is used to classify the agent's ôle.    -   Second, the engineering agent provides information on the        service level agreements the agents commit to and carry out. It        provides statistical data on the number of SLAs agreed to and        finally carried out, the amount of time per SLA, overall,        minimal, maximal time, etc. According to this data, agents are        classified as good or bad workers.    -   Third, based on the information of capacity of workload, work        committed to, and work actually carried out, the engineering        agent can recommend policies to increase the performance of        agents. If an agent commits itself, for example, to too much        work, but actually carries out little of it, the engineering        agent will recommend a more moderate bidding policy for at least        that agent.    -   Fourth, given the agents' local process descriptions, the        engineering agent generates the global process (i.e. the overall        business process run by the relevant APMS).    -   Fifth, the engineering agent analyses the agent's processes and        may detect deadlocks in the process or verify that the process        meets a given specification or satisfies certain properties.    -   Sixth, the engineering agent provides a 3D visualisation of the        agents' communication trace.    -   Seventh, the engineering agent clusters the agents dynamically        according to their distance which is defined by the number of        messages exchanged between two agents and which evolves during        the performance of the agent system.        4.5 Filters and Translators

Filters and translators are referred to above, with reference to FIG. 6.Filters are programs which receive messages from external agents andfilter out unwanted information. Translators take outputs from filters,transform them into SQL insert statements and populate the database.

Filters and translators are application dependent. They have to bewritten for each application. Filters take the requirements of currenttables and their descriptions and determine whether a given message froman application should be passed to translators. If a message is notrelevant to any table, the message is thrown away and filters wait fornext message.

Translators understand the exact syntax of a message and how informationshould be extracted from it. Type conversions are often required becausedifferent systems may use different types. Again translators cannot bedesigned generically.

FIG. 14 shows a flow diagram of the filtering and translating processes.

5. System Design Details

This section describes system-wide design details which are not specificto particular components in the infrastructure

5.1 Communications Mechanisms

AMS agents communicate with other agents by exchanging FIPA messages.The transportation is based on the CORBA standard. Each agent defines aset of standard IDLs which are required by any CORBA implementation. Inthis particular case, OrbixWeb from IONA inc. is used.

Each FIPA communicative act is represented by a one-way method of IDLinterface FIPA_CORBA. Each method specifies all possible keywords whichmay be required by that act. The keywords are specified in a fixedorder.

The interface is implemented in JAVA. The implementation of each IDLmethod is responsible to translate this CORBA representation into FIPAACL.

5.2 FIPA ACL

AMS deals with requests from external agents. These requests are:requesting visualisation services, storing information services andanalysing agent performance. In order to provide certain services, AMSneed data from external agents so that FIPA ACL requests to externalagents are issued. Only a subset of FIPA ACLs are required. AMS canprocess the following FIPA communicative acts:

inform The sender informs the receiver that a given proposition is true.request The sender requests the receiver to perform some action.request-when The sender wants the receiver to perform some action whensome given proposition becomes true. request-whenever The sender wantsthe receiver to perform some action as soon as some proposition becomestrue and thereafter each time the proposition becomes true again.subscribe The act of requesting a persistent intention to notify thesender of the value of a reference, and to notify again whenever theobject identified by the reference changes. cfp The action of callingfor proposals to perform a given action. cancel The action of cancellingsome previously requested action which has temporal extent. failure Theaction of telling another agent that an action was attempted but theattempt failed. not-understood The sender of the act informs thereceiver that it perceived that j performed some action, but that it didnot understand what j just did.

Each message has compulsory keywords and optional keywords. The contentslanguage used is PIF. The following is a list of compulsory keywordsassociated with each message.

-   -   inform: agent-id, conversation-id, contents    -   request: agent-id,conversation-id, protocol-used, contents    -   request-when: agent-id, conversation-id, protocol-used,        contents, conditions    -   request-whenever: agent-id, conversation-id, protocol-used,        contents, conditions    -   subscribe: agent-id, action    -   cfp: agent-ids, conversation-id, protocol-used, contents    -   cancel: agent-id, conversation-id, action-id    -   failure: agent-id, conversation-id, action-id    -   not-understood: agent-id, conversation-id, protocol-used,        contents

FIPA messages may obey certain FIPA protocols. AMS FIPA protocolprocessing is shown in FIG. 16. FIPA protocols are represented as Javaobjects. A protocol object represents an instance of a FIPA protocol,which is defined as a sequence of states. Methods are defined to updatethe protocol, to get the current state, to get next valid states and toget valid reply states.

The protocol handler of the MIA 153 takes an instance of a FIPAprotocol, a message and the protocol followed by the message. Uponreceiving a message, it extracts the message type, i.e. state in theprotocol terms. Then it checks this message against the protocol bycomparing the message type with the valid next states which can beobtained given the current state (IDL-ACL handler 405). If the messagefollows the protocol, the message contents are extracted (ACL messagehandler 410) and the contents handler 415 is called. If the message doesnot follow the protocol, a not-understood reply is constructed.

After contents processing, the protocol handler checks if the resultsare valid replies by comparing with next valid reply states. If thereply is not valid, an exception is raised to the contents handler 415.Otherwise, it constructs the reply and then the processing passes to theACL-IDL wrapper 420.

5.3 Event Query Language

Event Query language is used by AMS agents to store and retrieveinformation from its VDR 305. It is based on SQL with temporalinformation added.

5.3.1 Time Representation

To represent states and state transitions, a notion of time is required.AMS uses discrete time points to represent temporal information. Thispoint-based temporal logic is sufficiently expressive to representevents from agent systems. The reason is that all data are captured bymessages from agent systems and those messages are sent discretely atparticular points in time. Although a point-based temporal logic issufficient to time stamp messages, it is not flexible or convenientenough to express visualisation and engineering queries. For example,

Display the state of agent A at the completion of Task B.

Display resource usage during service C.

These types of queries cannot be easily constructed using a point-basedtemporal logic.

In MIA databases 155, all temporal information is represented as timepoints. AMS queries can use an interval based logic.

5.3.2 Event Query Language

AMS Event Query Language uses SQL to create and to populate databasetables. The retrieval parts are extended to allow users to expressqueries to use an interval logic and an event logic. In the AMS, Allen'sinterval logic can be used. This was published for instance in ACMCommunications 35 (11), 1983.

The AMS 100 defines a very simple event logic. Services and tasks arethe only events. Valid logical symbols are: and, or, before, after andjust-after. Their meanings are:

and logic AND or logic OR before time before an event, i.e. a service ora task after time after an event, i.e. a service or a task just-after atime point at which an event finishes

Apart from using the above to construct queries, the MIA 153 alsoprovides a set of high-level APIs for the VA 151 and EA 152. Typical APIqueries from these are:

-   -   Retrieve all tasks of agent agent-id.    -   Retrieve the state of a task at time point i.    -   Retrieve states of a task over time interval i.    -   Retrieve all the active instances at time i.    -   Retrieve all the time points where there are state changes.    -   Retrieve all negotiation messages sent out by agent agent-id.    -   Retrieve all negotiation messages received by agent agent-id.    -   Retrieve all negotiation messages between agent agent1 and agent        agent2.

This set of queries can be easily defined. In APMS agent systems,resources are tasks. Thus the status of an agent at time ti is thestatuses of all its task instances. Task instances in APMS agent systemsare predefined. Thus there are a fixed number of task instances at anyparticular time point or finite time intervals.

APIs are implemented in JAVA/JDBC and/or Pro*C/PL SQL. All API functionsfirst parse the inputs, then construct SQL queries and finally returns aset of answers.

The above example API queries are coded as the following SQL queries:

Retrieve all tasks of agent agent-id

select task-id from agent-task-instance

where agent-id=agent-id;

Retrieve the state of a task at time point i.

select state from task-instance

where time=i;

Retrieve states of a task over time interval i.

select state from task-instance

where time >i1 and time <i2;

-   -   (Note that time points i1 and i2 are derived from time interval        i by the API program after examining all time points in the        database.)

Retrieve all the active instances at time i.

select task-id from task-instance

where state=‘active’ and time=i.

Retrieve all the time points where there are state changes.

select distinct time from task-instance;

Retrieve all negotiation messages sent out by agent agent-id.

select message-id from event

where agent-id=agent-id and origin=0;

Retrieve all negotiation messages received by agent agent-id.

select message-id from event

where agent-id=agent-id and origin=1;

Retrieve all the negotiation messages between agent agent1 and agentagent2.

select message-id

from event, message

where

-   -   (event.event-id=message.event-id) and    -   (agent-id=agent1 or agent-id=agent2) and    -   (origin=0 or origin=1) and    -   (message.sender/receiver=agent1 or    -   message sender/receiver=agent2);        5.4 Contents Ontology

The contents ontology in the AMS 100 defines a common shared vocabularywhich APMS agents 172, 175 can use to construct their requests to AMSagents 150. It defines a set of terms and their semantics. AMS contentsontology is classified into three categories: MIA, VA and EA.

5.4.1 MIA Ontology

MIA ontology includes all table definitions in the MIA database 155 plusthe following:

store_message { agent: a1, message-type: t1, t2, . . . } store_message {agent: a1, a2, . . . time_interval: time }5.4.2 VA Ontology

VA ontology includes:

agency-view { agent: a1, a2 . . . message-type: m1, m2 . . .time-interval: start-time: display: 2d or 3d } agent-view { agent: a1tasks: t1, t2, . . . } domain view { service: service-id details:task-level animation: no }5.4.3 EA Ontology

EA ontology includes:

check-SLA { agent: a1 SLA: s1 } performance-report { agent: a1 style:html }5.5 Database Tables

The VDR 305 uses the Oracle database 155 to store information from theagents 172, 175 in the APMS 115, 120. There are two sets of databasetables in the VDR.

Tables in the first set are used to store inter-agent messages, whichare messages sent or received by agents. This set of tables is genericand can be used to store inter-agent messages from agent system, becauseinter-agent messages of agent systems have similar sub-components. Forexample, every inter-agent message has a sender and a receiver, and isnormally associated with a type such as propose, acknowledge, refuse,etc.

Tables in the second set are used to store internal states of agents.Unlike inter-agent messages, agent states are system specific, andcannot be defined without reference to a particular agent system.Therefore, a set of tables has to be designed for each agent system tomeet its specific needs.

All messages from agent systems are recorded in the VDR database 155whether they are inter-agent messages or state reporting messages. TheVDR 305 uses events to refer both to inter-agent messages and to statereporting messages. Inter-agent messages are simply called messages. Inthe following, a summary of all tables in the first set and some of thetables in the second set is presented.

5.5.1 Inter-Agent Message Events

There are three tables in the first category; they are event table,message table and message-contents table. FIG. 17 shows the relationshipbetween agent messages and events.

-   -   M: the message from agent A to Agent B    -   T1: the time at which agent A sends out the message M    -   T2: the time at which agent B receives the message M    -   T3: the time at which the visualiser receives the notification        from agent A, eg. Sending the message M at time T1    -   T4: the time at which the visualiser receives the notification        from agent B, eg. Receiving the message at time T2    -   T5: the time at which the agent sends its state report to the        visualiser    -   T6: the time at which the visualiser receives the status reports        from agent C        Event Table

event table holds every event from agent systems. It has six attributes:event-id, agent-id, a-time, v-time, origin, and system.

-   -   event-id: a unique id. for an event. It is generated by the VDR        and is used as the primary key for the event table.    -   agent-id: the id. of the agent which generated the event.    -   a-time: the time at which the agent agent-id sent or received        the message, or sent its state report. For example, if the        message was sent by agent A to agent B, and this event was sent        to the VDR by agent A, then agent-id is A and the time is the        time at which agent A sent the message to B. If the event was        from B, then agent-id is B and the time is the time at which        agent B received the message.    -   v-time: the time at which the VDR receives the event.    -   origin: a number denoting the origin of the event. It is 0 if        the event was from the message sender; it is 1 if the event was        from the message receiver. It is 2 if the event was reporting an        agent state.    -   system: the agent system id. This is required because we use the        same set of tables to record all messages from agent systems.        Message Table

message table is used to record all inter-agent messages. It is not usedto store agent state reporting messages. This table has four attributes:event-id, message-id, sender/receiver and message-type.

-   -   event-id: foreign key reference to the event table.    -   message-id: message id. used by the agent system. If the agent        system does not use message ids., VDR will generate a message        id. for every inter-agent message.    -   sender/receiver: agent-id. Its value depends on where the event        comes from. If the event was from the message sender, it is the        receiver agent id. Otherwise it is the sender agent id. The        agent-id of the event table and the agent-id of the message        table together provide information of a message's sender and        receiver.    -   message-type: the type of the message. Message type is very        useful information made explicit by the VDR. There are many        queries which are only concerned with message types instead of        message contents.        Message-Contents Table

message-contents table is used to store raw messages. It has twoattributes: message-id and message-contents. Although one inter-agentmessage generates two entries for the event table and message table, theraw message is only recorded once in the message contents table.

-   -   message-id: the id. of the message.    -   message-contents: the actual message.        5.5.2 Agent-State Events

Tables in this category have to be defined for each agent system. Thefollowing summarises some of the state tables for a selected APMS 115,120. There are eight tables used to store the agent states of thesystem. It should be noted that data used to populate these tables maybe derived from inter-agent messages. An appropriate filter has to bewritten for each APMS system to extract this information.

States of the APMS agents 172, 175 reflect the usage of resources whichinclude services, tasks and service level agreements. Tasks haveinstances, and these instances have execution ids.; each executioninstance has states. Services consist of tasks and can also includeother services (see FIG. 11).Agent_Task Table

agent_task table is used to record tasks controlled by agents. It uses acomposite primary key (agent id. and task type) because many agentscould perform the same tasks.

Agent_Task_Instance Table

agent_task_instance table is used to record a task and its instancesthat are controlled by an agent. This table is necessary becauseinstances of tasks can be deleted. Thus there are tasks which do nothave any instances.

Task_Instance Table

task_instance table is used to record instance states. The timeassociated with each state is the time at which the instance starts tobe in that state. Thus only the state transition is recorded in thedatabase.

Similarly there is a set of service tables: agent_service,agent_service_instance, service_instance. These service tables areanalogous to the task tables above.

The other two tables in the second category are service_task table andagent_sla table. service_task table is used to record the associationbetween a service and tasks or other services. agent_sla table recordsall the service level agreements. An example of an agent_sla table is asfollows:

Starting agent1 agent2 sla_id service_name Time a₁ a₂ 123provide_cust_ser 9.30 am a₁ a₃ 234 provide_cust_ser 9.30 am

An example of a service_task table is as follows:

Task Service Time T1 S1 T2 S1 T3 S1 Tn S1

The time column of the service_task table can only be instantiated whena service or task is actually run as this is the start time of theservice.

5.6 Presentation tools

This section covers the presentation screens, particularly for the“Domain View”, coded by the AMS 100. The Agent and Agency views arecommented on above.

Domain view

The domain view shows details about the underlying processes enacted byagents. This includes contract compliance, task and resource usage,business process execution, etc. Typical domain views are shown in FIGS.18–24.

Referring to FIG. 18, the contract compliance view shows the workactually carried out as bar charts and the previously agreed amount as aline.

Referring to FIG. 19, the Task Utilisation Chart is in the form of adynamic ‘ruled’ chart diagram.

Referring to FIG. 20, a task commitment chart for theProvide_Customer_Quote service is shown. Each line represents aparticular task type of the service. The number represents thepercentage utilisation of that task type. When the chart is active, thenumbers represent the task usage at a particular time interval. The TaskCommitment Chart shows the task usage as part of a particular serviceover a period of time. From the presentation of information provided bythis BME tool, a manager can see the historical trend of the task usage.

Referring to FIG. 21, a task status chart of thecapture_customer_details_L task as part of the Provide_Customer_Quoteservice is shown. The Task Status Chart is a pie-chart showing therelative proportion of tasks (belonging to the same task-type within aparticular service) that are in one of the following states: active,idle, in-jeopardy or failed.

Referring to FIG. 22, the Business Process Flow Chart is a flow chartshowing the progress of each individual customer's contract. The colourof each box represents the state of the task at that moment in time. Itallows the user to visualise the status of an execution of the overallbusiness process for an individual customer and to drill down to asub-business process by clicking one of the boxes.

Referring to FIG. 23, sub business process views can be displayed byclicking each task box.

Referring to FIG. 24, an SLA execution graph shows the actualrelationship between SLAs.

6. Implementation

This section gives some details of how the system is implemented.

AMS external interfaces to APMS agents are defined as a set of CORBAIDLs. These external interfaces are implemented using OrbixWeb from IONAInc. MIA is implemented in JAVA, Pro*C, PL/SQL. VA and EA areimplemented in JAVA, HTML and VRML. The packages used are JDBC, DaVinci.MIA also uses an Oracle database.

MIA is implemented in JAVA, Pro*C and PL/SQL. There are two ways toconnect to Oracle databases from JAVA: JDBC and/or JAVA native methods.Through JDBC, all database query APIs are defined as JavaEQL classmethods. These methods construct EQL queries from API parameters andthen pass them to EQL parsers which are defined in JavaEQLParser class.EQL parsers return SQL statements. These SQL statements are passed toJavaDatabase class where these SQL statements are converted to JDBCqueries to Oracle databases.

Through Java native methods, all database query APIs are defined as Javanative methods. These Java native methods are implemented in C. There isone to one correspondence between API queries and C functions. Each APIC function parses the query and then calls a Pro*C function to constructa PL/SQL query to access Oracle databases.

The service management module 310 manages all VA and EA requests. VA andEA requests are process by class ThreadManagement. It uses a vector tohold a current active request queue. Methods are defined to operate thisqueue such as inserting a new request, removing a request, and gettingrequest details. Each request is represented by a request object whichrecords details of the request.

DatabasePoller class defines methods which can feed data to VA at agiven rate. In case of run-time visualisation, all data are forwarded toVA as soon as MIA receives them. If the visualisation is off-line, dataare retrieved from databases and forwarded to VA at a particular rate.

6.1 EA implementation

6.1.1 Architecture

Referring to FIGS. 2 and 13, the EA architecture is composed of

-   -   the core EA which realises the agent's services,    -   an interface to the MIA 153 which breaks down high-level EQL        queries into SQL queries which are performed using JDBC    -   an interface to the VA 151 which prepares the EA's results for        visualisation    -   the concurrency workbench CWB as the data analyser 205 which        provides process verification    -   the graph drawing tool DaVinci (not shown separately)        6.1.2 Interface to the MIA 153 and Oracle database 155

The information necessary for the EA 152 is loaded to the Oracledatabase 155 by the MIA 153. In fact, much of the engineering agent'swork is physically carried out by the MIA providing high-levelinformation. In particular, the EA is provided with the followingmethods:

-   -   initMIA(user,password) connects to the database and returns a        statement used as reference by all subsequent calls.        The following calls all return ResultSets:    -   getAgents(stmt) returns agent names    -   getBadGuys(stmt) returns agent names of workers who did not        carry out their SLAs    -   getGoodGuys(stmt) returns all agent names of workers who did        their SLAs    -   getBusyBody(stmt) returns agent names, number of SLAs, average        time per SLA, sum of times for SLAs, minimal and maximal time        for SLAs, variance of times.    -   getInteragentcommunication(stmt) returns sender, receiver, and        number of messages exchanged ordered by number of messages    -   getInteragentcommunicationTrace(stmt) returns sender, receiver,        message type of messages sent ordered by time    -   getNumberMsgSent(stmt,name) returns number of messages sent by        an agent    -   getMsgSentTo(stmt,name) returns agents to which messages were        sent    -   getMsgTypeSent(stmt,name) returns the types of messages sent    -   getNumberMsgRecvd(stmt,name) returns the number of messages        received    -   getMsgRecvdFrom(stmt,name) returns the agents from whom messages        were received    -   getMsgTypeRecvd(stmt,name) returns the message types received    -   getNumberSLAs(stmt,name) returns the number of SLAs committed to    -   getNumberSLAsDone(stmt,name) returns the number of SLAs carried        out    -   getSLAInfo(stmt,name) returns average time per SLA, sum of times        for all SLAs, minimal and maximal time per SLA for a particular        agent    -   getWorkload(stmt,name) returns capacity, committed and actually        carried out workload for a particular agent    -   getInitialSLA(stmt) returns the SLAs which do not have        predecessors wrt temporal order    -   getGlobalSLAsucc(stmt,sla) returns the successors of an SLA wrt        a temporal order and independent of a particular business        process    -   getSLAsucc(stmt,sla,bp_context) returns the successors of an SLA        wrt a temporal order and a business process

The interface realises the methods by according views on the database.

6.1.3 Engineering agent (Class EA)

Using the methods provided by the above interface, the engineering agentimplements the following services:

-   -   getAgentOverview( ) returns an address of a web page with        general information of the analysed multi-agent system    -   get3Dtrace( ) returns an address of a VRML page containing a 3D        animation of the multi-agent system's performance    -   get2Dclustero returns an address of a HTML page loading an        applet that animates the agents' closeness evolving over time    -   getagent(name) returns an address of a web page with information        on a particular's agent performance    -   monitor SLAexecution( ) returns an address of a page containing        a graph in DaVinci Format. The graph represents the temporal        order of SLA execution per business process.    -   verifyProcesseso verifies all processes and returns its findings        as an address of a web page.    -   getGlobalProcesso constructs a global process out of the local        processes and translates the results to the DaVinci graph format        which allows visualisation of the result.        6.1.4 Agency: agent overview (EA.getAgentOverview( ))

To give an overview over the multi-agent system, the agents areclassified as good or bad workers depending on their carrying out allSLAs they committed to. Additionally, various statistical data on theSLAs is given, such as minimal and maximal time per SLA, average, sumand variance. To judge the closeness of two agents, the agent overviewprovides a table with the number of messages sent from one agent toanother. This table allows identification of active and passivecommunicative agents.

6.1.5 Agency: 3D trace (EA.getTrace3D( ))

VRML is used to visualise the communication of a multi-agent system, theVirtual Reality Markup Language. VRML allows specification ofthree-dimensional worlds and animation of the worlds' objects. Athree-dimensional visualisation is superior to a two-dimensional one ifa large number of agents communicate. The VRML worlds allow the observerto navigate in the world and thus he or she can fly from one clique ofagents to the next without losing the overview of the scenario.

VRML primitives are used to specify viewpoints, agent and message nodesand clocks. Basically, for each agent and each message a node iscreated. The agents are located on a circle with the message at theposition of the sender. Initially, all message nodes are invisible. Toanimate the messages a path from the sender to the receiver of themessage is specified. Additionally, for each message there is a clock.If a clock is activated, it emits events for one cycle and the messageis made visible and traverses from the sender to the receiver during theclock's cycle. At the end of the cycle the message disappears again andthe clock of the following message is triggered.

Positioning agents on a circle is only useful for a small number ofagents. For large agent communities a general positioning algorithm hasbeen developed. A technique called spring embedding is used on adistance table where distance could be inversely proportional to thenumber of messages exchanged between two agents or the number ofinterests shared by two agents, or the distance could actually mimicphysical distance (which is an interesting option for mobile agents).The distances are seen as gravity forces and in an iteration an agent's“gravity field” is computed and the agent is moved a small step in thecorresponding direction. After a number of iterations there is a fairlygood approximation to the distances specified in the distance table.

6.1.6 Agency: clustering (EA.getCluster2D( ))

Given the trace of the agents' communication, the clustering places theagents initially at random positions. In temporal order, eachcommunication between two agents links them with an edge labelled bytheir actual distance. For each following communication of these twoagents the labelled (and thus their distance) is decreased. For everycommunication taking place between other agents, the label is increased.Given these distances, a directed force is computed for everycommunication for each node. The force is computed by assuming thatnodes if not connected repel each other, whereas connected nodes attracteach other to reach exactly the distance specified by their label. Oncethe direction is computed, the node is moved in that direction.

6.1.7 Agent: agent information (EA.getAgent(name))

For each agent there is page describing its individual performance.Based on the speech acts the agents send and receive they are classifiedas managers or workers. Besides the statistical data already presentedin the overview page, the individual workload of the agent is analysedfor all SLAs it carried out. This analysis is summarised in arecommendation either to increase/decrease workload, bid more balancedfor SLAs, or simply continue.

6.1.8 Domain: monitor SLA execution (EA.monitorSLAexecutiono( ))

Given a business process, a specification defines a general order inwhich the agents involved may execute their SLAs. For a particularinstance of the business process, it is possible to view the actualexecution in a graph representation.

6.1.9 Domain: verify processes (EA.verifyProcesses)

Processes are specified in PIF, the process interchange format. Badperformance of an agent may be process inherent. That is, if the agentsunderlying business process is not properly designed, it misses itstargets. Given the formal representation of an agent's business process,it is possible to verify various properties. CCS, the calculus forconcurrent systems, is used to analyse and verify business process.Given the translation from PIF to CCS, as defined below, and theconcurrency workbench, a verification tool for CCS, it is possible todetect for instance whether a process contains deadlocks or matches amore abstract specification.

To translate PIF into CCS, only three PIF constructs are needed: thedecisions and activities, and the successor relation over the decisionsand activities. The predecessor relation is obtained from the successorrelation. Additionally, it is assumed that there is only one initialactivity. The case of more than one initial activity can be reduced tothe case of one by introducing a new initial activity whose successorsare the previous initial activities.

Basically, the algorithm treats the process as a graph and traverses itdepth-first beginning with the initial activity. In case a node isvisited the first time and it has other predecessors an acknowledgementis sent for all predecessor except for the parent node visited in theprevious step. Next, the node's action (activity or decision) is carriedout and then for each branch leaving the node the algorithm is calledrecursively. Depending whether the node is an activity or a decision,the results are composed by summation or parallel composition. In thecase that the node has already been visited, the acknowledgement sent inthe first visit is received. The algorithm is called with the currentand its parent node and the set of acknowledgements to be synchronisedas arguments. For the initial node no parent is given which isabbreviated as no_parent.

Algorithm:

-   -   Input: A set of nodes, i.e. decisions and activies, the        successor and predecessor relation succ and pred, and an initial        node n.    -   Initialisation: Unmark all nodes, call (CCS,Ack)=PIF2CCS(n,        no_parent,{ }), return CCS\Ack

PIF2CCS(n,parent,Ack) returns a CCS expression

if marked(n) then return ('ack_parent.0,Ack+{ack_parent})

else

mark n;

CCSAck=“”;

while there are nodes m in pred(n)\{parent} do

-   -   CCSAck=CCSAck+“ack_m.”

CCSSucc=“”;

if succ(n)={ } then CCSSucc=“0”;

for all m in succ(n) do

-   -   (CCSSucc2,Ack)=PIF2CCS(m,Ack);    -   if n is activity then CCSSucc=CCSSucc+“|”+CCSSucc2    -   else CCSSucc=CCSSucc+“+”+CCSSucc2

od

return CCSAck.n.(CCSSucc)

6.1.10 Domain: construct global process (EA.getGlobalProcesso( ))

Only the local business processes of agents are given and it isnecessary to construct the overall process when the agents collaborate.Given the PIF specification of the local processes, one can detect theinterfaces between the agents and connect exit points in one processdescription to entry points in the appropriate process descriptions ofother agents. The resulting process describes the overall behaviour ofthe agent system.

6.1.11 Interface between engineering agent and visualisation

Since all services of the engineering agent are delivered as web pagesthe interface to the visualisation is simply realised by passing the webaddresses. In a user interface, different views can be bought given ausername and password to access the database. If bought, the servicesare delivered as hyperlinks to web pages containing the correspondingresults.

6.2 Filters and translators

Filters and translators are implemented in Proc*C and PL/SQL. They canalso for instance be implemented in JAVA. Filters filter out irrelevantmessages by inspecting current database table requirements. Translatorsextract contents of messages and transform them into Oracle types.Filters and translators are not generically applicable because differentagent systems have their own contents languages and syntax. Thefollowing describes how they are implemented in Proc*C and PL/SQL.

Filters are simple Pro*C programs. They use a structure pointer torepresent database table requirements. The structure has three fields:{agent system, message type, database table}. The filter program takes amessage and determines which agent system the message is from. If theagent system appears in the structure, the message type is extracted.Otherwise, the message is discarded. Then it will decide whether thepair <agent system, message type> is related to any database table. Ifthe message is related to a table, the filter program calls thetranslator program. Otherwise, it is discarded.

-   -   The translator program first determines whether the message is        an inter-agent message or an intra-agent message. Then it is        passed to either inter-agent message translators or to        intra-agent translators according to which agent system the        message comes from. Note that translators have to be written for        each agent system.

In translator programs, each message type is processed by a translationfunction which extracts relevant fields of the message, then convertsthem to Oracle types, and finally constructs SQL statements.

1. A performance visualization system for use in storing and visualizingperformance data representing the performance of multi-agent systems inmanaging processes, said performance visualization system comprising: i)a request input for receiving a performance visualization servicerequest in respect of a multi-agent system; ii) a performance data inputfor receiving performance data inputs from the multi-agent system; iii)a service definitions store for storing a set of data visualizationservice definitions each comprising a data visualization serviceidentifier and one or more service requirements in relation, theretosaid service requirements including identification of data inputsrequired for provision of said performance visualization services inrespect of each data visualization service; iv) performancevisualization service request processing means for accessing a serviceidentifier in a received performance visualization service request; v)service identifier processing means for selecting a service definitionfrom the service definition store in accordance with an accessed serviceidentifier; vi) a performance data input store for storing performancedata inputs from the multi-agent system required for provision of theperformance data visualization service associated with an accessed datavisualization service identifier; and vii) means to associate datainputs received from a multi-agent system with the multi-agent systemwhich generated the performance data, together with means to review thecontents of the performance data input store for entries in respect ofthat multi-agent system.
 2. A performance visualization system as inclaim 1, the system also comprising a visualization tool store forstoring a set of visualization tools.
 3. A performance visualizationsystem as in claim 1, wherein said service definitions store defines adata storage service in which data inputs of one or more types arestored in the data input store.
 4. A performance visualization system asin claim 3 having means to map data inputs identified by a first servicedefinition to data inputs already stored in accordance With a secondservice definition.
 5. A performance visualization system as in claim 2,the system further comprising a visualization tool input for loadingvisualization tools to the visualization tool store, said store beingprovided with an index of tools currently loaded.
 6. A performancevisualization system as in claim 1 which system also comprises dataanalysis means.
 7. A method of visualizing performance data representingthe performance of systems in managing processes, said methodcomprising: i) receiving a performance visualization service request inrespect of multi-agent system; ii) receiving performance data inputsfrom the multi-agent system; iii) storing a set of performance datavisualization service definitions in a service definition store, eachsaid service definition including a data visualization serviceidentifier and identification of data inputs required for provision ofsaid data visualization service; iv) accessing a performance datavisualization service identifier in a received performance datavisualization service request; v) selecting a service definition fromthe service definition store in accordance with the accessed serviceidentifier; and vi) storing data inputs in association with themulti-agent system making the performance visualization service request,which performance data inputs have been identified by the selectedservice definition.
 8. A method as in claim 7, the method furthercomprising: loading one or more service definitions to the servicedefinitions store, subsequent to receiving performance data inputs fromthe multi-agent system, said subsequently loaded service definition(s)identifying at least one of said data inputs previously received.